Enterprise Migration Practice Detailed Steps For Migrating Core Services To The US CN2

1.

Overview of migration background and objectives

Migration goal: Place core business nodes in a US data center, while improving packet loss and latency from Chinese mainland to the US through dedicated CN2 lines.
Business requirements: Ensure 99.9% availability, peak concurrency support, and prioritize latency-sensitive RPC requests.
Key constraints: compliance and data sovereignty, cross-border bandwidth costs, DDoS risk assessment.
Metrics: Average RTP latency (ms), packet loss rate (%), availability (%/month), bandwidth utilization (Mbps).
Common misconceptions: blindly pursuing the lowest bandwidth while ignoring peak concurrency, not implementing rollback solutions, and ignoring the impact of domain TTL and DNS switching.

2.

Assessment and preparation before migration

Asset inventory: List all domain names, certificates, backend hosts, databases, message queues, and dependent third-party APIs.
Traffic Analysis: Analyze traffic curves hourly, daily, and weekly to identify peaks, bursts, and long-term average bandwidth. Example: Daily average outbound bandwidth 30Mbps, peak 250Mbps.
Latency measurement: Use MTR, ping, and TCP traceroute to record RTT and packet loss to US nodes. The recommended sampling interval is 72 hours.
Compliance checks: Confirm cross-border data compliance, filing, and user privacy requirements, and prepare necessary contracts and backup policies.
DNS and certificate preparation: shortened domain TTL, prepared wildcards or multi-server room certificates, and tested the automatic renewal process.

3.

Network architecture and routing design

Choosing a link: Evaluate types such as CN2 GT and CN2 GIA; CN2 generally offers a more stable cross-border path with lower latency.
BGP Strategy: Configure different AS routing strategies for the primary/backup lines, and adjust MED and LocalPref to control traffic direction.
Private links and public network redundancy: It is recommended to use CN2 + IPLC or SD-WAN for link aggregation, CN2 for the main link, and standard international bandwidth for the backup link.
Load distribution: Deploy global load balancing (GSLB) and health checks at near-source points within the country, allocate traffic by geography and latency.
Monitoring and Alerts: Deploy real-time traffic monitoring, BGP routing change monitoring, and packet loss alerts, with SLA triggering automatic switching.

4.

Server and instance configuration examples (including table display).

Design principle: Separate front-end, application, database, and cache, and try to separate hot standby and read/write as much as possible.
Example List: List typical instance types, CPU, memory, disk, and bandwidth planning as follows.
Cost considerations: Measure hourly instance fees against bandwidth costs, estimate monthly costs, and allocate a 30% flexible budget.
High availability solution: Database master-slave deployment across AZ, application layer uses multi-AZ load balancing.
The table below shows a typical configuration example (centered table, border width 1, text centered):
, , , , : , ,

Role	: CPU	memory		disk export bandwidth
Web nodes	: 4 vCPUs	8 GB	100 GB SSD	200 Mbps
App	nodes: 8 vCPU	16 GB	200 GB SSD	500 Mbps
DB main	16 vCPU	, 64 GB	1 TB NVMe	1 Gbps
Cache/queue	8 vCPU	32 GB	200 GB SSD	500 Mbps

5.

Data synchronization, migration steps, and switching strategies

Phased migration: first perform read-only synchronization, then perform application switching, and finally perform write switching and cutback point confirmation.
Data synchronization tools: Use rsync + lsyncd for file increment, MySQL master-slave or GTID-based binlog synchronization.
Verification steps: Run a full regression test in the target environment, perform stress tests, and monitor thread count, connection count, and latency performance.
DNS switching strategy: Lower TTL to 60 seconds, gradually increase traffic weight, and switch to full data after observing metrics.
Rollback solution: Retain short-term dual-write/bidirectional synchronization windows, allowing rollback to the original site within 24 hours after switching.

6.

Security, CDN, and DDoS defense practices

CDN strategy: Front-end static resources are distributed through multi-vendor CDNs (near-source + global), with APIs using self-managed reverse proxies.
WAF and Speed Limiting: Use WAF strategies at the edge to block common attacks, limiting login/interface speed to prevent brute-force brushing.
DDoS protection: Set cleaning thresholds (for example, triggered when SYN flooding exceeds 50 kpps or traffic exceeds 500 Mbps), and negotiate traffic cleaning with upstream operators.
Encryption and authentication: Uses TLS1.2/1.3 and HTTP Strict Transport Security, with interfaces employing short-term tokens and signature mechanisms.
Logs and Traceability: Centralized logs, Netflow, and alerts are integrated to ensure rapid source location and upstream cleaning during attacks.

7.

Real Case: Migration Practice of an Online Education Company

Background: The company peaked at 12,000 concurrency, with most users in China mainland, but course videos and core APIs hosted in the US.
Before migration: Users had an average RTT of 320ms to the US API, packet loss of 2.1%, and homepage loading time of 4.8 seconds.
Measures: Connect to the US host cluster via CN2 dedicated lines, use GIA-type links, and deploy CDN + WAF at multiple points in China.
Migration effect: average RTT reduced to 120ms, packet loss decreased by 0.3%, and first screen load time was 2.1s. Peak bandwidth smoothed from 250Mbps to 520Mbps (including video retrieval).
Configuration example: 6 app clusters (8vCPU/16GB), 1 DB master (16vCPU/64GB NVMe), read-only from 2; CN2 dedicated line at 1Gbps, with a monthly link cost of about 38,000 RMB (including bandwidth and link maintenance).

8.

Monitoring, optimization, and long-term operational recommendations

Continuous monitoring: Establish SLO metrics panels for RTT, packet loss, HTTP 5xx, DB connection count, and queue length.
Cost optimization: Regularly assess bandwidth peaks and reserve resources, and use automatic scaling to reduce base costs.
Regression testing: Conduct traffic playback and performance regression tests after each dependency or architectural change.
Documentation and Drills: Maintain detailed switching and rollback documentation, and regularly rehearse the switching process in case of failure.
Supplier relationships: Establish SLA agreements with CN2 providers, specifying cleanup, bandwidth limits, and fault response times.